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This nemo attempts to formalize the notions of process, process 
control states, inter-process control transfers, context, and 
naming environments for processes. 

PROCESSES} 

(Processes) A process has the following attributes: 

" (Control) 

Control(S) is a pair (pc, status) consisting of a 
control pointer into some body of code associated with 
the process and a value denoting the status of S, chosen 
from the list in the branch labelled States below. 

(Context) 

Conceptually, the context for a process is the set of 
objects which the program can access by simple names. 
Since we view an activation record for a procedure, for 
instance, as a compound object whose components 
correspond to the local variables of the procedure, it 
is convenient to view the context of a process s simply 
as a vector of "references" to objects whose components 
can be accessed by simple identifiers in the source 
program. 

An element of the context is a pair (CA, IND), where CA 
is the address of an object whose semantics matches S's 
requirements for the object specified by the context 
slot, and IND, if one, implies indirection {take the 
value of the object to which CA points as the CA for 
this entry) . 

The only way a process can touch any object is via the 
context vector. This includes the data objects called 
ports which are used for all control transfers, and the 
context vector itself (which must be accessed as a data 
structure for replacing context entries, for instance). 

Accessing an object via a context entry whose CA value 
is NIL is not currently defined, -but ix would be nice if 
it would generate a signal. 

(Ports) A Dort is simply a plug and a socket for forming a 
control connection from the port's process to another. A port 
has no state in its own right. The attributes of a port are 
the following: 

(Owner) we denote the owning process of a port Q by 
owner(Q). 
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(To) If a port Q is not connected, we say To(Q)=Nilj if Q 
is connected to another port Q', we say To(Q)=Q<. 

Note that there is no requirement that To(To(Q))»Q. 

Of course, To(Q)-Q is perfectly valid. 

Some more global definitions; 

A configuration is just a set of processes. 

We would like to arrange things so that a well-behaved 
configuration can have its ports interconnected and its 

processes started in any order. 

CONTEXT OF A PROCESS: 

It is NOT assumed that the context vector is physically 
attached to the data structure wnich contains the variables 
for the process. 

There are a number of distinguished entries in every process's 
context {entries marKed with a * are considered aynamxc and 
must be set whenever a new incarnation of a process is 
created} : 

(SYSTEM) system transfer structure for access to system 
facilities; this is a component of every process's context, 
although it does not have to have the same value in tnem 
all. 

(RETURN)* Pointer to port over which control will leave if 

S RETURNS, 

(PENDING)* If S is Pending (0.) , then the PENDING entry 
point-s to Q. 

initially the PENDING entry will point to a P° rt 
"declared" at comoile time called, the process's RETURN 
port; the D rocess's control pointer is initialized from 
information obtained at compile time also. 

(CATCH)* The innermost catch phrase to be called if a 
signal is passed to S. 

(SIGPATH)* pointer to the process to which signals which 
are not caught by S should go. 

in the following list of allowable operations on context 
vectors, Ctx stands for a pointer to a context vector, i for 
an integer value, and x for an arbitrary value. 

Newctx «- Copycontext (Ctx) j 
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SetcontextEntryCCtx, i, x)j 
x «- ReadContextEntry (Ctx, i) J 
DeleteContextEntry (Ctx, i); 

Set the i*th context entry to NIL, 
"DeleteContext (Ctx) ; 
PROCESS CONTROL STATES: 

(States) The possible states of a process are: 

(P) pending (Q) : Pending on port q«, i.e. control last left 
by a successful call through port q. 

This includes the case of one process starting another, 
which is just a call on a system facility (over a port 
of course) 

When a process is created, it is initially in state 

?( START) where START is a distinguished port used as the 

inport for a function or the starting point for a 

process. 

(R) Running. 

At most one process can be in state R at a time. 

(RESUMA3LS) 

Process can be started by control over any one of its 
ports- or by a START operation directed at the process. 

(Transitions) The transitions between the possible states of a 
process are represented in the following diagrams 
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INTER-PROCESS CONTROL TRANSFERS: 

port Calls: the following MPS procedure describes port calls: 

(Portcaii) PROCEDURE (port, outparamlist) ; 

IF port. owner n S THEN ERROR QnvalidPortcall, port); 
MafcePendin? (S» port); 

(checkFaults) DO begin i loop until no problems with 
the control transfer 
(For Re try) BEGIN 

IF (Object-Port «. port«To) « NIL 

THEN BEGIN 

signal «• ResolutionFault; 
EXIT ForRetry; 

END; 
ResoivePortfobjectPort, port); mote that 
PortCall does this and not xfer. 
Ob jectProcess «• Objectport. Owner; 
IF NOT Pending (Ob jectProcess, oojectPort) 
THEN BEGIN 

signal *• ControlFault; 
EXIT ForRetry; 
END; 
EXIT CheckFaults; 
END ForRetry; 
t generate sisnal and anticipate control resumption 

via RESUME or port 

inparanlist *- SIGNAL (signal, port); 
IF outparamlist « NIL THEN RETURN (inpararalist) ; 
END CheckFaults; 

inparanlist «- xfer (port, Qbjectport, outparamliat); 
i basic control transfer 
RETURN (inparanlist); 
END. PortCall 

Note: 

If a oort is connected to itself, then its owning 
process immediately regains control as if the port call 
had not occurred at all. 

The mechanism works correctly after any linkage fault is 
generated whether control arrives over the port or as 
the result of a RESUME by someone who caught the signal. 

Procedure Calls: the following procedure describes procedure 
calls: 

(ProcedureCall) PRGCEDURS(port, outparamlist) J 

NewProcess +> copyProcess (port. To. owner) ; 
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inparanlist *■ PortcalK Port (Owner: NewProcess, To; 
port. to), outparamlist); mow perform a normal port call 

RETURN (inparamlist); 

EKD. 

.This description of the procedure call mechanism has a 
number of consequences: 

The caller is specifying that a procedure call is to be 
made rather than the callee or the callee's inport 

specifying it. 

The call is a two step operation involving the 
construction of a subsidiary port over whicn control 
goes after a copy of the callee is nade. If this new 
port is not constructed, then the next time the caller 
uses the Riven port, it will no longer have owner 
pointing to the orotoprocess and the copy of the 
non-protoprocess may have altered lots of context 
entries. 

The callee creates his local variables and enters them 
into his context himself; this is not done for him. >t 
is assumed that the initial control pointer points at a 
place in his coae body which will make an activation 
record for local values (this closely models procedures 
in most current Algol-like languages). 

possible solutions; 

Let the inport to the callee contain the knowledge that 
it sonifies whetner a new copy of the process named by 
port.To. owner is to oe made. Then simple port calls 
would look exactly like procedure calls on the calling 
side. It also could allow the implementation of 
FOFTRAN-like procedures which conceptually acquire local 
storage the first time they are called and then retain 
it thereafter. 

This model of entry on a port is close to that 
proposed by BWL and suggests that the "knowledge in 
the inDort could simply be the address of some system 
facility for copying the procedure and pointing the 
procedure's RETURN port (which is copied as a _ 
consequence of copying the process ??) back at the 
caller's porx,. Note that a RETURN operation from the 
callee snould not resolve the caller's port to the 
callee's RETURN port since that causes the problem 
that the caller does not want to go to the callee 
copy which returned to him. but to a new copy. 
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Signal Control: 

Normally the SIGPATH context entry is altered in 
conjunction with the RETURN entry. When a signal is 
generated by a process, the innermost CATCH "procedure" is 
called with a local environment containing 

(a) the signal code 

(b) the paramlist which accompanies the signal code 

The context within which the catch phrase is executed 
includes the part of the context of the process in which 
the catch phrase lives which is accessible to it. 

A catch phrase nay do one of two things which affect -the 
signal propagation: 

It nay allow the signal to continue propagating. 
possibly stating the direction which it is to take 
(SIGPATH for the process containing the catch phrase 
defines the default direction) . 

It may do a "non-local" transfer of control into the 
body of its containing process s via the port on which S 
is pending, prior to the actual resumption of S, 
another signal is passed from the point of generation of 
the original signal. This new signal, called UNWIND, 
destroys any processes which allow it to propagate. 
Once it reaches s, the resumption takes place* 

During the time it is deciding which of these two courses 
to take, the body of a catch phrase may do any call or 
other evaluation whicn it pleases. However, all "backward" 
control transfers (RETURN, SIGNAL, ERROR, and EXITs which 
are not local to the body of the catch phrase) are 
interpreted as performed on behalf of S, 

PROCEDURES AND PROCESSES AS DIFFERENT MANIFESTATIONS OF THE SAME 
PHENOMENON 

This section explores the similarities between processes and 
procedures (in the traditional sense) . 

When a procedure is called in Algol the following events take 
place: 

the caller constructs a parameter list 

return linkage information is allocated in a place 
accessible to both the caller and the callee 

the caller fills in the return information 
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control passes to the entry point for the procedure in some 
body of code 

the callee allocates space for local variables 

when the callee is done, he deallocates the local variables 

■control passes back to the caller via the return linK 
information 

the parameter list is deallocated along with the return 
linkage information 

in terms of our model for processes this paradigm can be 
restated as 

the caller constructs a parameter record 

a copy of the callee protoprocess is created: this includes 
his context information, and control/status 

the callee' s RETURN port is resolved back to the port which 
S is using for the "call" 

the callee 's context is .altered to include the parameter 
record 

control passes to the callee 

the callee creates an instance of its activation record 

when the callee is done, he allocates and constructs a 
return record 

the callee frees his activation record 

control passes back to the caller over the process's RETURN 
port and the callee copy is destroyed 

PROCESS CREATION: 

An instance of a process is nothing more than a (Control, 
Context) pair, processes can be created by copying "already 
existing process (however, this is not quite what one would 
like, namely copies of the data structures created by the 
process itself -- but see the next paragraph). Initially a 
process is created from some virgin form which has usually 
been established from a file, we will call such an object a 
protoprocess: it is not an executable entity, but holds a 
place in the naming environment and creating a process from it 
is a simple operation. 

A protoprocess consists of a partially initialized context and 
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initial control information. If the records created by the 
process for local variables, etc. could be created 
independently of one another, then making a copy of an already 
existing process and the data structures owned by it would be 
a simple operation, in general this is not the case: records 
contain references to other records, and hence, truly copying 
a process is equivalent to copying a set of inter-referential 
records. I don't think we should provide a built in facility 
to- do this -- it is a job for someone using the system. 

Creating a new process s from some already existing process or 
protoprocess P is simply a matter of copying the control and 
context information for P to S. 

PROCESS NAMING ENVIRONMENTS; 

Compile Time: 

The local variables for a process or procedure are those 
declared following the header statement for the process. 

The following example demonstrates this: 

(Exl) PROGRAM (al, bl); 
DECLARE rl, Si, tl; 
body-1 

(Ex2) PROGRAM (a2, b2); 
DECLARE r2, s2, t2j 

body-2 

END. 
END. 

When an incarnation of Exl is initially created, space 
is allocated for al, bl, cl, rl, si, and tl. Thereafter 
whenever Ex2 is called {which is equivalent to creation 
followed immediately by control transfer), a2, b2, ..., 
t2 are allocated and will be deallocated only when Ex2 
does a RETURN. 

The prototype program from which a process can be created 
is the following: 

(Example) PROGRAM (parameter-list); 

local-variable-aeclarations; 

program-body 

END. 

Any gathering of many program prototypes in one source file 
is simply a way of binding some contexts before process 
creation time and of causing one CREATE operation to result 
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in the creation of a number of processes, stated 
differently, a source module is a means of binding 
processes into configurations before creation tine. 

A local-variable-declaration may be' 

a program declaration: this allows Algol-like bindings 
of context. 

an INCLUDE declarations incarnations of any objects 
declared in the INCLUDE module will have the same 
lifetime as normal local variables. 

Execution Time: 

The execution tine naming environment consists of a tree 
whose nodes are processes and instantiations of data 
modules. More than one instance of a process or data 
module can reside at a node of the tree. Also, separate 
instances of the same process nay reside at different nodes 
in the naming tree. A given process resides at exactly one 
node, in the naming tree. 

The naming environment is not necessarily coupled with the 
control or context of processes although it is often 
convenient for them to be associated. All normal bindings 
of names to objects use the compile time symbol table 
associated with a process as the most local information, 
and the naming tree as the next source of names. 

Ve add trie following attributes to those listed above for 
processes: 

(parent) parentis) is S's ancestor in the naming tree, 

(Sibling) sibling(s) is a process such that 
Parent(S)s?arent(Sibling(s) ) or Sibling is) = NIL 

(Child) Child (S) is the "first" descendant process of S 
in the naming tree. The children of a process are 
well-ordered, and the following loop will access all the 
immediate descendants of d! 

child «• Child(S): 
UNTIL child=NIL 
DO BEGIN 

process this child; 
child <• sibling (child) j 
ENDJ 

EXAMPLE: 
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Primitive operations for Process Creation and calling 
Procedures: 

(createrromFile) PROCEDURE (filename) ; 

DECLARE POI.MTER(PORT) CalllnPort; 

a «- Mapln (filename) ; 1 -^ap file into addressable memory 

CalllnPort *• ProtoProcess (a.XnitialPC, a, 

self .ReturnPort.To) ; make a protoprocess with initial 

control from the file and parent, my caller 

return (Callinport) ; J give hack address of port by 
which process can be called 

END. 

(ProtoProcess) PROCEDURE (pc, codebase, parent); 
inaKe a protoorocess with initial pc as given. -in the 
codebase given and with the specified parent process 

DECLARE POINTER (PROCESS) p; 

p <- copyProcess(SkeletonProcess, parent); i make a 
minimal, virgin process 

p. Control <- pc; 

p. context. Pending *• s (p.ReturnPort) ; 1 initial state is 
Pending (ReturnPort) 

p. Context. CodeBase *■ codebase j 

Startup. To «• p.ReturnPort; 

xfer (startup. Startup, NIL); 

RETURN (Startup. To) ; 1 really not, necessary since 
Startup belongs to caller of ProtoProcess 

END. 
Sample Program Outline; 
(a) ROUTINE (pa, qa) ; 
DECLARE xa, ya, za; 
(al) ROUTINE (pal, qal); 
DECLARE xal, yal, zalj 
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body of alj 
END Of al. 
body of a; 
END of a. 

Tiie following purports to be the code generated by the MPL 

compiler for tne sample program above; 

Proto-code for a's protoprocess 
(aProto) 

DECLARE PROCESS p, POINTER (PROCESS) ap, POINTER ( PORT) 
calleri 

p <- GopyProcess (SkeletonProcess, self); Iprototype 
process descriotor for a 

I set any of p's context which is desired 

p. Control *■ iSaBEGINS; 

xfer{Return?ort, Returnport, self .inargs) ; 

i The following loop handles creation and calling of 
instances of a. 

DO begin I loop forever 

ap «- CopyProcess(p, seif)j Icopy of preset 
process descriptor for a 

caller «• ReturnPort.To; 

Returnport. To «- ap.ReturnPort; iso can transfer 
control to ap and leave aproto pending Returnport. 

xfer{Return?ort, caller, self .inargs) ; 

I aProto is left pending his ReturnPort and has 
cut himself out of the control path from the 
caller to the instance of a. 

ENDj 

Code for the routine a: 

(aSEGINS) 

DECLARE xa, ya, za, PORT CALLal; 
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CALLal, Owner ♦• self; 

CALLal. To *• Prot-oProcess (alProto, alProto, self); 

body of a 
code for al's protoprocess 
(alProto) 

DECLARE PROCESS p, POINTER ( PROCESS ) alp, POINTER ( PORT) 
caller; 

p «- copyProcessfSkeletonProcess^ self); 

p. Context. GLQ5ALS *■ ReturnPort .To. Owner . Context . LOCALS; 
llocal variables of enclosing preear included in context 
of any incarnation of al. 

p. Control *■ &al3EG2NS; 

xfer (ReturnPort, ReturnPort, self .inargs) ; 

{ The following loop handles creation and calling of 
instances of a. 

DO BEGIN I loop forever 

alp - CopyProcess(p, self); icopy of preset 
process descriptor for a 

caller «• ReturnPort. To; 

'Re-curnPort. To «• alp. ReturnPort; I so can transfer 
control to alp and leave aProto pending 
ReturnPort. 

xfer (ReturnPort, caller, self .inargs) ; 

J alProto is left pending his ReturnPort and has 
cut hinself out of the control path from the 
caller to the instance of al. 

END; 
code for al 

(aiBSGINS) I code for al 
DECLARE xal, yal. sal; 1 nake local record for self. 

body of al 



